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Abstract 

Collaboration models and tools aim at improving the efficiency and effectiveness of 
human interactions. Although social relations among collaborators have been iden- 
tified as having a strong influence on collaboration, they are still insufficiently taken 
into account in current collaboration models and tools. In this paper, the concept of 
service protocols is proposed as a model for human interactions supporting social 
requirements, i.e., sets of constraints on the relations among interacting humans. 
Service protocols have been proposed as an answer to the need for models for hu- 
man interactions in which not only the potential sequences of activities are specified 
- as in process models - but also the constraints on the relations among collabo- 
rators. Service protocols are based on two main ideas: first, service protocols are 
rooted in the service- oriented architecture (SOA): each service protocol contains a 
service-oriented summary which provides a representation of the activities of an as- 
sociated process model in SOA terms. Second, a class-based graph — referred to as 
a service network schema — restricts the set of potential service elements that may 
participate in the service protocol by defining constraints on nodes and constraints 
on arcs, i.e., social requirements. Another major contribution to the modelling of 
human interactions is a unified approach organized around the concept of service, 
understood in a broad sense with services being not only Web services, but also pro- 
vided by humans. 

Keywords: human interaction, social requirement, process modelling, service 
protocol, social network 



1. Introduction 

An important goal of many information systems is to support human interac- 
tions. The spectrum of information systems focusing on human interactions is very 
broad, from critical systems such as air traffic control systems, to most modern 
video games, such as World of Warcraft. Among enterprise information systems, 
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both enterprise resource planning (ERP) and customer relationship management 
(CRM) management systems aim at supporting human interactions. 

The development of service- oriented architecture (SOA) and business process 
management (BPM) has lead to a new approach to the design and implementation 
of information systems. In this approach, information systems are designed and im- 
plemented around the concept of decoupled and orchestrated processing entities, 
referred to as services. 

Currently, SOA is mainly applied at the infrastructure level, with most develop- 
ment efforts related to the implementation of SOA with Web services and WS-* stan- 
dards. Business Process Modelling in the context of SOA leads to the orchestration 
of Web services for which two standards are prevalent: WS-BPEL |3| for Web services 
orchestration, and BPMN |20 1 for more business-oriented and higher-level models. 

The importance of human interactions in the context of SOA and BPM has been 
lately recognized. Emerging standards, such as WS-BPEL Extension for People (usu- 
ally shortened to BPEL4People) |2| and WS-HumanTask |4|, aim at providing bet- 
ter support for activities performed by humans in the BPEL framework. However, 
these two standards do not recentre BPEL around human- to -human interactions 
but rather propose a formal definition of human activities and potential inclusion 
of these tasks within a BPEL process. As a consequence, information systems devel- 
oped in the SOA paradigm are usually supporting human interactions in a limited 
and insufficient manner. 

The main reason for the poor computer support for human interactions in the 
context of SOA and BPM is the difficulty to model social elements involved in the 
interactions among humans. An attempt to encompass social elements involved in 
the interactions among humans is the introduction of the concept of a role. A role 
usually defines the right to perform a limited set of activities within a given process. 
Depending on one's social position or competences, various roles maybe attributed. 
Another approach, popular in social networking websites such as Facebook (9) or 
Linkedln 1 16], consists in linking individuals and organizations with a set of prede- 
fined types of relations, such as "Friend" or "Connections". 

Neither roles nor predefined types of relations reflect the complexity of social 
elements that play an important role in the interactions among humans. Some ex- 
amples of such social elements are positions within a given hierarchical structure 
of an organization, trust relations, past cooperation, and recommendations among 
humans. 

Although many information systems support human interactions, they do not 
encompass social elements. As a consequence, there is a mismatch between the 
support for human interactions provided by the information systems and the social 
elements, part of the social norm that is ruling the interactions among the humans 
using the information system. Among various manifestations of this mismatch, so- 
cial networking websites are often violating rules defined in the social norm, leading 
to legal and ethical issues. An example is the possibility on Facebook to publish a 
photography about a person without the consent of this person: such a situation is 
usually condemned by social norms as a privacy violation, except in the case when 
the allowed viewers of the photography are friends or close family. Facebook sup- 
port for human interactions could be improved by taking into consideration the re- 
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lations between the photographed person and the viewers, i.e., social aspects, al- 
lowing only friends and close family to access the photography. 

Therefore, there is a need for novel models of human interactions, especially 
models encompassing social elements, to develop information systems supporting 
human interactions in a more efficient and effective manner. The concepts of ser- 
vice and process model that underlies SOA and BPM should be extended to encom- 
pass social aspects and their influence on the human interactions. 

In this paper, a formalization of social requirements for human interactions is 
proposed as a novel model of human interactions supporting social aspects is pro- 
posed. Social requirements are defined as sets of constraints on relations among 
interacting actors. In the presented model, referred to as service protocols, a process 
model defining actors and their potential sequences of activities is extended by a set 
of constraints concerning both the actors and their relations. As an example, while a 
model for the process of house building defines potential activities for the architect, 
for the building company, and for a gardener, a service protocol may ensure that the 
architect and the building company have a long cooperation history and that the 
building company and the gardener have the same suppliers. 

The rest of this paper is organized as follows. First, a rationale for service pro- 
tocols is presented in Section|2] In Section[3] related work is presented. Next, some 
basic notions related to classes, graphs, processes, and services are presented. Then, 
a formal model of service protocols is presented in Section[5] Potential applications 
of service protocols are proposed in Section [6] A discussion of service protocols is 
presented in Section]?] Finally, Section[8]concludes this paper. 

2. Rationale for Service Protocols 

In this section, the rationale for service protocol is presented. First, a running 
illustrative example grounded in the construction sector is introduced. Next, based 
on the running example, a set of key issues is identified. Then, the goals of service 
protocols are presented. Finally, a list of requirements for service protocols is pro- 
posed. 

2.1. An Illustrative Example 

To introduce the main key issues that service protocols aim at addressing, a run- 
ning example grounded in the construction sector is presented in this section. For 
the sake of readability of this paper, the presented example is much simpler than 
real cases. 

Let assume that a real-estate developer company, named DevHouse, is planning 
its next investment. D currently owns a field in which an old abandoned oil refinery 
is standing in ruins. Dplans to build a supermarket in this field. Dis an experienced 
real- estate developer with 24 investments. 

First, Dshould obtain a loan from a bank to finance the investment. To ease the 
whole procedure, Dwants to focus on banks with which it has already collaborated. 
Therefore, Dplans to negotiate a loan with banks at which it currently has an ac- 
count, and from which it has got former loans. However, Dwould like to avoid a 
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next loan at a bank from which it already has a current loan. Finally, banks propos- 
ing interest rates higher than 5.5% for a 3-year loan should be rejected. A potential 
candidate for a bank financing D's project is MoniBank. MoniBank is a commercial 
bank with about 235.500 clients, offering a 3% interest rate for 3 -year loans. Dhas an 
account and no current loan at MoniBank. 

Second, Dneeds an architect to develop the construction plans. A major require- 
ment concerning the architect concerns past and current collaboration. As the su- 
permarket is a strategically important investment for D, the architect should have 
at least five former projects performed for D, but less than two projects currently 
performed. A potential candidate for the architect is a Canadian architect, named 
Archibald Tex, responsible for 17 investments. Archibald Tex collaborates with Don 
3 current projects, following a collaboration on 15 past projects. 

Third, Dneeds the field to be cleaned. The developer does not want to be in 
charge of the supervision of the clearance process. The architect should be respon- 
sible for identifying a site preparation company, which will supervise the preparation 
tasks, i.e., demolition and rubble removal. The two companies that will perform the 
preparation tasks, i.e., a demolition company and a debris hauling company, should 
be known and trusted by the architect. Additionally they should be able to efficiently 
collaborate. 

The remaining tasks required to build a supermarket, e.g., foundation construc- 
tion, masonry, carpentry, are not taken into account in this paper. 

2.2. Key Issues 

Although a classical case in the construction sector is described in the formerly 
presented illustrative example, a set of issues related to this case are still to be ad- 
dressed. 

2.2.1. Multiple Service Consumers 

In a traditional orchestration approach, various service providers are provision- 
ing the service interfaces that, assembled together, form a process. As an example, a 
BPEL process model usually relies on various service providers, but only one service 
consumer exists: the BPEL engine that is executing the process instance. 

In the formerly presented illustrative example, as well as in many cases of collab- 
oration among companies, a process consists not only of various service providers, 
but also various service consumers. In the example, a first service consumer is D, 
the real- estate developer, that is seeking for financing from banks. Next, a second 
service consumer is the architect that needs a site preparation company to super- 
vise the cleaning of the field. Finally, the site preparation company itself is a service 
consumer when it consumes the demolition and rubble removal services provided 
by the demolition company and the debris hauling company. 

Not only multiple service providers, but also multiple service consumers should 
therefore be encompassed in models for collaboration. As a consequence, collabo- 
ration could be modelled as a set of collaborators — the service consumers — perfor- 
ming activities provided by actors — the service providers. 
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2.2.2. Constraints on Actors 

In a traditional BPM approach, process models define constraints on the poten- 
tial sequences of tasks and the concept of role is used to limit the execution of a 
given task to individuals with the appropriate rights. In short, a process model de- 
fines who may do what, and when. However, it should be noted that the "who" part, 
i.e., the role definition, is usually limited to a label associated with a set of tasks that 
may be performed. A process role defines a set of rights. 

In the formerly presented illustrative example, a process model may define that 
each individual playing the Real-estate Developer role may perform the ne- 
gotiate a loan task. A real-estate developer may negotiate a loan if financing 
is needed. However, if the investment may be fully financed by the real-estate de- 
veloper, a loan (and the associated negotiations to obtain it) may be avoided. 

Another type of constraints may be identified: some tasks may be performed 
only by actors with appropriate characteristics. Although process roles define rights, 
constraints on actors define obligations. The obligations associated with a given 
actor may be considered as a definition of the "who" part formerly mentioned. 

In the formerly presented illustrative example, a constraint on an actor being 
a Real-estate Developer may state that her number of investments 
has to be greater than ten. Any real- estate developer with a lesser number of in- 
vestments should not be allowed to participate in the formerly presented process. 
Similarly, banks proposing interest rates higher than 5.5% for a 3-year loan should 
be rejected. 

Although constraints on actors are often concerning their competences to per- 
form a given taslQ constraints on actors may concern a multitude of aspects of ac- 
tors, e.g, their physical trait^Jor their place of living 

2.2.3. Relational Constraints 

A second type of constraints may be identified: relational constraints. Some 
tasks may be performed only by actors with appropriate relations with other actors. 
Similarly to constraints on actors, relational constraints define obligations. How- 
ever, while the constraints on actors focus on the essential characteristics of an ac- 
tor, i.e., the characteristics of the actor in isolation, the obligations defined by rela- 
tional constraints focus on the environment of the actor and her social place in this 
environment. 

In the formerly presented illustrative example, the choice of the architect is lim- 
ited by relational constraints: the architect should have at least five former projects 
performed for D, but less than two projects currently performed. Similarly, the choice 
of the bank is limited by relational constraints: Dis interested only in banks at which 
it has a bank account, former loans should have been obtained from the bank by D, 
and currently D should not have any loan from the bank. 



: As an example, architects usually have to complete an appropriate examination to be licensed, such 
as the Architect Registration Examination (ARE) for Canadian architects. 
2 In a soccer team, the goalkeeper should rather be tall. 

3 In election-related processes, the place of voting is usually related to the place of living. 
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2.3. Goals of Service Protocols 

First, service protocols aim at providing a model for service-based collabora- 
tion encompassing the multiplicity of service consumers. Traditional process mod- 
els, e.g., BPEL, are usually based on the assumption that, although the responsibility 
for activity execution is spread among actors, only one actor — usually the process 
engine — is responsible for activity invocations. In SOA terms, traditional process 
models assume a single service consumer and various service providers. In many 
collaboration processes, e.g., the formerly presented illustrative example, various 
service consumers are collaborating. Service protocols tackle the problem of col- 
laboration processes in which the responsibility for activity invocations is spread 
among various actors, i.e., various service consumers. 

The second goal of service protocols is to support the definition of constraints on 
actors, both service providers and service consumers. In traditional process models, 
actors are usually related to roles. A role provides actors that play it with the right to 
perform a set of activities in given states of the collaboration process. Constraints on 
actors are a means to define the obligations that an actor has to fulfil to participate 
in the collaboration process. 

The third goal of service protocols is to support the definition of relational con- 
straints between actors. Although the importance of social aspects in collaboration 
processes has been largely studied (7), traditional process models still lack support 
for relational constraints. Service protocols provide support not only for constraints 
on actors, but also for the constraints concerning the relations between them. As a 
consequence, although traditional process models focus on possible sequences of 
activities associated with a set of roles, service protocols extend traditional process 
models by providing means to define constraints concerning the group of actors that 
may execute a given process model. 

2.4. Requirements for Service Protocols 

Based on the set of requirements presented in (23) , the following requirements 
for service protocols supporting human interactions in SOA may be articulated: 

1 . reusability: a given service protocol should be reusable to rule the interactions 
within various groups of collaborators; A service protocol aims at modelling 
a set of collaboration processes, in the same way as a class models a set of 
objects in object-oriented programming. In other words, a service protocol 
may be seen as a model whose instances are collaboration processes; 

2. separation of activities implementation from service protocols: a service pro- 
tocol should model potential interactions among collaborators, however the 
interactions should be decoupled from implementation of the activities per- 
formed by collaborators. As a consequence, activities of a given service proto- 
col may be implemented in various ways, using various technologies, or vari- 
ous locations/hosts; 

3. strong mathematical foundations: service protocols model complex cases of 
potential interactions among humans. Therefore, strong mathematical foun- 
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dations are required as a mean to check properties such as structural validity, 
reachability, liveness and boundedness of the proposed models; 

4. support for social aspects in collaboration: human interactions are strongly 
related to social aspects. Social aspects may limit the choice of collabora- 
tors, impose some relations among interacting humans. Most process mod- 
elling languages and notations do not provide designers of process models 
with means to explicitly capture social requirements concerning collaborators 
in the process model. Computer support for human interactions should treat 
social requirements, i.e., constraints on the relations among actors of human 
interactions, as an integral part of the model of human interactions. 

With regard to (23) , although the three first requirements have just been adapted 
to service protocols and the SOA context, the fourth requirement has been added to 
stress the importance of social requirements expressed as constraints on the rela- 
tions among actors of human interactions. 

3. Related Work 

3. 1 . Business Process Modeling in SOA 

In the BPM literature, information required to model and control a process has 
been classified according to various perspectives. In (31], five perspectives have 
been presented: 

• the functional perspective focuses on activities to be performed, 

• the process perspective focuses on the execution conditions for activities, 

• the organization perspective focuses on the organizational structure of the 
population that may potentially execute activities, 

• the information perspective focuses on data flow among tasks, 

• the operation perspective focuses on elementary operations performed by ap- 
plications and resources. 

The introduction of BPEL4People and WS-HumanTask may be considered as an 
attempt to address the organization perspective. However, the proposed solution is 
rather an attempt to integrate human interaction in business processes composed 
by Web services. BPEL4People and WS-HumanTask do not address various key as- 
pects of human interactions: Mendling et al. have identified a set of limitations of 
BPEL4People concerning the important issue of separation of duty in human inter- 
action 1 18'| . Similarly, Russell and van der Aalst have shown the boundaries of the 
expressiveness of BPEL4People and WS-HumanTask, detailing a set of workflow re- 
source patterns that the two standards do not implement (27) . 

Holmes et al. have remarked that BPEL4People and WS-HumanTask are the re- 
sult of rapid changes in technologies associated with SOA 1 14 1. As a consequence, 
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they propose a model- driven approach to business processes, including basic sup- 
port for human interactions. The proposed model-driven approach is based on sim- 
ple assumptions about human interactions, especially concerning roles. However, 
social requirements are missing in the presented model. 

3.2. Computer Support for Human Interactions 

Computer support for human interactions has been the subject of research in 
various research communities, from computer support for collaborative work (CSCW) 
and workflow management systems to BPM and adaptive case management (ACM). 

CSCW and workflow management systems focus mainly on the handling of doc- 
uments in a processing chain to which various persons are participating. CSCW 
and workflow management systems are adopting a document- routing approach in 
which social aspects are not addressed. These systems have been studied and de- 
veloped mainly in the 1990's, with a major result being the publication in 1995 of the 
Workflow Reference Model 1 13] by the Workflow Management Coalition (WfMC). 

In a workflow approach, it is assumed that a process may be designed and im- 
plemented once and for all. Most workflow management system were based on 
this disputable assumption. Next, business process management techniques have 
been developed to support changing process models. A direct consequence of this 
shift from workflows to business processes is the later development of SOA based 
on Web services and appropriate languages to model business processes, e.g., BPEL 
and BPMN. 

Swenson has shown that, although BPM focuses on predicable processes, a large 
number of processes are by nature unpredictable (28). He coined the term Case 
Management (ACM) that refers to a new approach to support knowledge work, i.e., 
work which is not repeated, unpredictable, emergent and robust in the face of vari- 
able conditions. As an example, the work of a fire rescue crew member is usually not 
repeated as each fire is different, is unpredictable as the situation on the fireplace 
may hardly be foreseen, is emergent as the immediate work of the crew member is 
determined by recently discovered knowledge about the fire situation, and robust 
in the face of variable conditions as the fire rescue crew member should be reliable 
and perform efficiently whatever the fire situation found. 

In ACM, a fundamental idea is that a process may not be modelled a priori (as 
in BPM), but the design of a process model should be performed at run-time, while 
the human interactions are ruled by the process model. A similar idea has been 
largely studied by Harrison-Broninski [TT]. Harrison-Broninski has identified that 
many human interactions are based on flexible, innovative, collaborative human 
activity. As a consequence, Harisson-Broninski has proposed to define a new class 
of systems, Human Interaction Management Systems (HIMS), which would sup- 
port flexibility, innovation and collaboration in human interactions. Although so- 
cial relations are mentioned a few times in [TT] as a potential information that may 
be relevant for flexibility and innovation, the weakest point of both Swenson's and 
Harrison- Broninski's works remains the lack of clearly articulated solutions to the 
very well presented set of issues. 

Finally, the concept of Social BPM has been recently proposed and is the sub- 
ject of various research efforts, with associated events such as the 3 rd Workshop 
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on Business Process Management and Social Software | 6 | at the 8 th International 
Conference on Business Process Management (BPM2010). However, among vari- 
ous definitions of Social BPM [I2l[26), a consensus seems to appear around the idea 
that Social BPM is about the use of social media and Web 2.0 approach to the design 
of process model. Therefore, in the Social BPM approach, wikis and blogs may be 
used to co-author a process model, allowing collaborators to design in a collabora- 
tive manner the model for the process within which they are collaborating. In any 
case, the concept of social requirements as part of the process model is associated 
with Social BPM. 

3.3. Social Requirements 

A preliminary remark concerning social requirements is that, although the term 
is widely used, it is usually not defined. As an example, social requirements are di- 
rectly mentioned in 1 1 1 without the provision of a definition. 

A definition of social requirements may be found in |29|, where social require- 
ments and social network analysis are associated as follows: "Social Network Analy- 
sis may be used to examine a given network by evaluating some of its properties. So- 
cial requirements may be considered as the reverse approach: social requirements 
may be used to define some properties of a network and their associated expected 
values, that may then be used to check if an existing network satisfies these social re- 
quirements." A definition of the relation between social requirements and process 
model is however still missing, as well as a formal definition of social requirements. 

4. Background 

In this section, the concepts related to object-oriented graphs are defined. Next, 
the main concepts related to processes and services in the SOA approach are de- 
fined. These notions are fundamental for a good understanding of the concept of a 
service protocol presented in Section[5] 

4.1. Object-oriented Graphs 

We define two kinds of object-oriented graphs: object-based graphs and class- 
based graphs. 

4.1.1. Object-based Graphs 

An object is a set of properties o = {p}. A property p is a pair (n>v n ) } where n is 
the name of the property and v n is the value of the property. The value of a property 
may be a literal or an object. 

As an example, consider the object Archibald Tex, illustrated in Figure[l]and 
defined by the following set of properties: 

• (nationality, Canadian), 

• (profession, {Architect }), and 
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• ^realizations^], 17). 

In Figure [I] the external rectangle represents the object Archibald Tex, while 
each inner rounded rectangle represents a property of this object. 



Archibald Tex 




Figure 1: An example of an object 

A set of objects and their relations may be modelled as an object-based graph. 

Definition 1 (Object-based Graph ) An object-based graph g = (N, A) is a graph 
whose nodes ne N are objects, and arcs connecting nodes ae A consist of a source 
object, a destination object, and an object describing the arc itself. 

To illustrate the concept of a object-based graph, consider a second object defin- 
ing a real-estate developer DevHouse by the following set of properties: 

• (name, DevHouse), 

• (profession, {Real-estate Developer }), and 

• ( tinvestments, 24). 

A simple object-based graph — illustrated in Figure|2]— may consist of the Archi- 
bald Tex, DevHouse, andMoniBank nodes. Nodes Archibald Tex and Dev- 
House are connected by an arc modelling the Collaboration between the ar- 
chitect and the real- estate developer defined as: 

• ( jfcurrentProjects, 3 ), and 

• ( #pastPro ject s , 15). 

The second arc — DeveloperBank — connects DevHouse andMoniBank. 

In Figure|2] the three nodes Archibald Tex, DevHouse, and MoniBank, are 
represented by rectangles, while the arcs between them are represented by arrows. 
Objects describing the arcs, i.e., Collaboration and DeveloperBank, are rep- 
resented by rectangles stuck to the arrows. The properties of both the nodes and the 
objects describing the arcs are represented by inner rounded rectangles. 



4 The symbol # should be understood as "number of". Therefore, "Realizations" should be understood 
as the number of realizations. 
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B| Collaboration 



H| DeveloperBank 



#currentProjects: 3 
#pastProjects: 15 



IB 



nationality: Canadian 
profession: {Architect} 




Figure 2: An example of an object-based graph 



4.1.2. Class-based Graphs 

A class is a set of property constraints c = {p a }.A property constraint p a is a pair 
(n f d n ) f where n is the name of the properties that p a may constrain, and d n is a 
predicate. 

As an example, consider a class Experienced Architect 6 *, defined by the 
following set of property constraints: 

• (profession, d {Architect }), and 

• ( trealizations, >15). 

The class Experienced Architect a is illustrated in Figure [3] The exter- 
nal rectangle represents the class Experienced Architect**, while each inner 
rounded rectangle represents a property constraint of this class. Note the use of the 
'a' Greek letter to mark class-related entities. 



Experienced Architect" 



profession: D {Architei 







Realizations: >1 



Figure 3: An example of a class 
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A set of classes and their relations may be modelled as a class-based graph. 



Definition 2 (Class-based Graph) A class-based graph g a = (N a ,A a ) is a graph 
whose nodes are classes, and arcs connecting nodes consist of a source class, a des- 
tination class, and a class describing the arc itself. 

To illustrate the concept of a class-based graph, consider a second class defining 
anExperiencedDeveloper a by the following set of properties: 

• (profession, d {Real-estate Developer }), and 

• ( tinvestments, >10 ). 

A simple class-based graph — illustrated in Figure [3]— may consist of the Expe- 
rienced Architect 6 *, Experienced Developed and Bank a nodes. The 
nodes Experienced Architect 6 * and Experienced Developer" are con- 
nected by an arc associated with the class Col lab or at ion 6 * defined by the fol- 
lowing set of properties: 

• ( jfcurrentProjects, >2 ), and 

• ( #pastPro ject s , >5 ). 

The second arc — DeveloperBank a — connects Experienced Developer" and 
Bank". 




a 



#currentProjects: 



#pastProjects: >5 



i 



Experienced Developer" 



profession: D {Real-estate Developer} 



#investements: >10 



aj Experienced Architect" 

profession: d {Architect} 



^realizations: >15 



hasAccount: = true 
#currentl_oans: =0 



terestRate: > 5.5% 



Bank a 



Figure 4: An example of a class-based graph 



In Figure[3] the three nodes Experienced Architect 6 *, Experienced De- 
veloper 61 and Bank 6 *, are represented by rectangles, while the arcs between them 
are represented by arrows. Classes describing the arcs, i.e., Collaboration 61 and 
DeveloperBank a , are represented by rectangles stuck to the arrows. The proper- 
ties of both the nodes and the classes describing the arcs are represented by inner 
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rounded rectangles. Note once again the use of the 'a' Greek letter to mark class - 
related entities. 

An object o = [p = (n, v n )} is an instance of a class c = [p a = (n,d n )} f denoted 
occ, iff all the property constraints of the class c are satisfied by the properties of the 
object o. A property p = (n, v n ) satisfies a property constraint p a = (n',d n /), denoted 
p > p a , iff the name of the property and the property constraint are identical, i.e., 
n = n' y and the predicate is true for the value of the property, i.e., d n t (v n ) = true. 

Formally, 

o c c o V p a e c,3p e o : p > p a . 

The object Archibald Tex is an instance of the class Experienced Archi- 
tect a because all the property constraints of the class are satisfied: Archibald 
Tex is an architect and his number of realizations, i.e., 17, is higher than the required 
number, i.e., 15. Note that additional properties, e.g., the nationality, are not 
relevant for the class Experienced Architects 

The object Archibald Tex is not an instance of the Experienced Devel- 
oper a class for two reasons. First, the profession property constraint of Expe- 
rienced Developer a is not satisfied by (prof ession, Architect). Sec- 
ond, no property named # investments is even defined for Archibald Tex. 

4.2. Processes 

A process is a set of activities which realize a business objective or a policy goal 
in a structured manner. A process instance is a single enactment of a process. 

An activity is a "piece of work that forms one logical step within a process" l32l . 
An activity may be automated work performed by information systems, e.g., creating 
invoices by a Web service , or work performed by humans, e.g., making a decision by 
a senior executive. 

A state is a "representation of the internal conditions defining the status of a pro- 
cess instance at a particular point in time" (32) . In its simplest form, a state may be 
reduced to a label, e.g., item produced. 

Definition 3 (Process Model) A process model n a is a triplet (5, A, j), where S is a 
set of states, A is a set of activity descriptions, and % is a relation % : A x S. 

The x relation captures the possibility to execute a given activity in a given state: 
the activity described by a e A may be executed in the state 5 e 5 iff a%s. 

4.3. Services 

An actor is an entity (human or non-human) or organization of entities that is 
capable of action. 

A need is a measurable requirement that an actor is actively seeking to satisfy. 
A capability is an ability to achieve an effect. 

Definition 4 (Service) A service is an access to a capability of an actor, called a ser- 
vice provider, to satisfy a need of a second actor, called a service consumer, where the 
access is provided via a prescribed interface fT7ll8l. 

A service interface is the means for consuming a service. It is admitted that an 
actor may provide a service to itself. 
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5. Formal Model of Service Protocols 



In this section, a formal model of service protocols is presented. First, the main 
elements of service protocols are introduced in an informal overview. Next, service- 
oriented summaries, service network schemata, and service protocols are formally 
defined. 



5.1. Overview 

Besides a process model defining the sequences of activities that may be per- 
formed during a collaboration process, a service protocol contains additionally two 
elements: a service- oriented summary and a service network schema. 

A service- oriented summary provides a representation of the activities of an as- 
sociated process model in SOA terms. The goal of the service- oriented summary of a 
service protocol is to represent activities of the process model as services, with each 
service consisting of a service consumer, a service interface, and a service provider. 
A service- oriented summary provides an abstraction of the activities as services in- 
dependently of the language used to model the process, e.g., BPEL or BPMN, focus- 
ing on the links between service consumers, providers, and interfaces. 

A service network schema is a class-based graph that restricts the set of potential 
service elements, i.e., service consumers, interfaces, and providers, that may partic- 
ipate in the service protocol by defining constraints on nodes and constraints on 
arcs, i.e., social requirements. The goal of the service network schema of a service 
protocol is to define the set of collaborators that is required to execute the associ- 
ated process instance. 



As regards requirements for service protocols articulated in section 2.4 



service- 
oriented summaries address partially the second requirement — separation of activ- 
ities implementation from service protocols — by providing a means to describe ac- 
tivities in an abstract manner, independently of the underlying process model lan- 
guage. Service network schema addresses the fourth requirement — support for so- 
cial aspects in collaboration — as a means to capture social requirements concern- 
ing the collaborators. The third requirement — strong mathematical foundations — is 
tackled by the formal model of service protocols presented below. 



The first — reusability — and the second requirement — separation of activities im- 
plementation from service protocols — are addressed by providing four layers for 
service protocols: abstract, prototype, executable service protocols, and service pro- 
tocol instances. An abstract service protocol does not provide any information con- 
cerning the implementation of the services. A prototype service protocol provides 
a partial implementation of the services defined in its service- oriented summary. 
An executable service protocol provides a complete implementation of the services 
defined in its service- oriented summary and may be instantiated. 

The implementation of services encompasses implementations of service pro- 
viders, service interfaces, and service consumers. In the proposed approach, it is 
assumed that a service network is available as the source of service implementation 
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used to build and instantiate executable service protocol. A service network is a net- 
work whose nodes are service providers, service interfaces, and service consumers. 



5.2. Service- Oriented Summaries of a Process Model 

In service protocols, the set of activities and states associated with a given type 
of human interactions are defined in a process model. No assumption is made on 
the chosen process modelling language or representation. 

The idea underlying service- oriented summaries is to provide a common rep- 
resentation of activities in a process model, independently of the chosen process 
modelling language or representation, in terms of service consumers, service inter- 
faces, and service providers. 

In a service -oriented summary of a given process, all the activities that may 
potentially be performed during the execution of this process are represented by 
triplets defining the "who" (the service consumer) , "what" (the service interface), and 
"whose" (the service provider) part of the activity. These triplets are referred to as 
service descriptions. 

Definition 5 (Service Description) A service description is a triplet s% = ( sc a , si a , 
sp a ) e S^ y where sc a is a class of service consumers, si a is a class of service inter- 
faces, and sp a is a class of service providers. 

A class of service consumers may for instance be the Experienced Archi- 



tect 6 * class defined in the illustrative example from Section 2.1 Following on this 
example, a class of service interfaces may define access to printing services with 
constraints such as (CAD plotting support, d {bond, vellum}), (pay- 
ment means, d {bank transfer, credit card}). Similarly, a class of ser- 
vice providers may define construction printing companies with constraints con- 
cerning the industry sector, the geographical location, etc. 

Based on the definition of service description, a service- oriented summary of a 
process model may be defined as follows. 

Definition 6 (Service- Oriented Summary of a Process Model) A service- oriented 
summary n® os is a triplet (n a , S^, p), where n a is a process model, S^ is a set of ser- 
vice descriptions, and p : A -> S^ is a function mapping activity descriptions in n a to 
service descriptions in abijective manner, i.e., Vs^ e S%, 3\ae A such that p(a) = s%. 



Note that the only constraint on the process modelling language is the possibility 
to associate service descriptions with the activities to be performed in the associated 
process model. As a consequence, various process modelling languages, e.g., BPEL, 
BPMN, may be used to model processes further summarized by service- oriented 
summaries. 

The concept of service -oriented summary of a process model is illustrated in Fig- 
ure [5] in which three service descriptions are represented as rectangles on the left 
side. Each service description contains a class of service consumers, represented 
by a rounded rectangle labelled s c { i } , a class of service interfaces, represented by 
a rounded rectangle labelled s i { i } , and a class of service providers, represented 
by a rounded rectangle labelled sp { i } , where i e 1,2,3. Next, three dashed arrows 
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are connecting service descriptions with the activities of the process model repre- 
sented by rounded rectangles labelled al, a2, and a3. These three arrows visualize 
the mapping function p. Besides the activities, the process model of the service- 
oriented summary contains a set of states, represented on the right side of Figure[5] 
The dashed arrows between the activities and the states represent the % relation that 
captures the possibility to execute a given activity in a given state. 



S Service description 1 




a 


si a 



< al 



Service description 2 




Service-Oriented Summary 
H Process Model 

:S Activities ^ 




B States 



Si 



L) 



< a2 



< 1-> a3 



Figure 5: A service-oriented summary of a process model 



5.3. Service Network Schemata 

Service networks aim at capturing properties and relations among service enti- 
ties, i.e., service consumers, service interfaces, and service providers. Service net- 
work schemata aim at capturing classes of service entities and their relations. Us- 
ing an analogy with concepts from object-oriented programming, service network 
schemata may be considered as classes defining some "templates", while service 
networks may be considered as objects, each service networks consisting of its own 
"state" being its set of service entities. 

5.3.1. Service Networks and Schemata 

Definition 7 (Service Network) A service network is a network of service entities. A 
service entity is an actor or a service interface. 

A service network may be represented by an object-based graph, in which ser- 
vice entities are represented by object-based nodes and links by object-based arcs. 

To emphasize service orientation, the graph-related terms "object-based nodes" 
and "object-based arcs" are further replaced by their service network- related terms, 
i.e., "service entities" and "links between service entities", respectively. 
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Definition 8 (Service Network Schema) A service network schema is a network in 
which entities are classes of service entities, and links are classes of links between 
service entities. 

A service network schema may be represented by a class-based graph, in which 
classes of service entities are represented by class-based nodes and classes of links 
between service entities by class-based arcs. 

To emphasize service orientation, the graph-related terms "class-based nodes" 
and "class-based arcs" are further replaced by their service network-related terms, 
i.e., "classes of service entities" and "classes of links between service entities", re- 
spectively. 

5.3.2. Memberships 

Compliance of a service network with a service network schema has a global 
character, although it is based on the local concept of membership. Membership 
refers to a particular type of relations that may exists between objects and classes in 
a service network and a service network schema. 

Although various types of membership may be defined in service networks and 
service network schemata, class relational membership and link class full member- 
ship have to be defined for a further definition of compliance. 

Definition 9 (Class Relational Membership) A service entity e is a relational mem- 
ber of a class of service entities e a , denoted e c e a , iff 

(1) e is an instance of e a , 

(2) for each class of links starting from e a and associated with a class c, at least 
one link starting from e is associated with an instance of class c, and 

(3) for each class of links leading to e a and associated with a class c, at least one 
link leading to e is associated with an instance of class c. 

Formally, 

'l) e^e a , 

2) Vl a = {e a ,e° st ,c),ll = {e,e dsb o) : o«=c, 

3) Vl a = (e% rcf e a f c) f 3l = (e srCf e f o) : o^c. 

In the example presented in Figure [2] and [5] the service entity DevHouse is a 
relational member of the class Experienced Developed. 

First, DevHouse is a member of the class Experienced Developed. 

Second, there is only one class of links starting from the class of entities Expe- 
rienced Developer a : DeveloperBank a . All the constraints — hasAccount 
and IcurrentLoans — defined in the class asso ciated with the DeveloperBank a 
class of links are satisfied by the object associated with the link DeveloperBank. 
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Third, there is only one class of links leading to the class of entities Experi- 
enced Developer a : Collaboration**. All the constraints — jfcurrentPro- 
jects and #pastPro ject s — defined in the class associated with the Collab- 
orat ion a class of links are satisfied by the object associated with the link Col- 
laboration. 

Note that the class relational membership of a given service entity e to a class 
of service entities e a is established on the basis of (1) the properties and property 
constraints of e and e a , and (2) the properties and property constraints of the links 
and classes of links starting and leading from/ to e and e a . Therefore the service 
entity Archibald Tex (respectively MoniBank) not being a instance of the class 
of service entities Experienced Architect 6 * (respectively Bank a ) is irrelevant 
for class relational membership of DevHouse. 

Definition 10 (Link Class Full Membership) A link / = ( e srC} e^sv °) is afull member 
of the class of links l a = (e^ rc , e% sV c), denoted l*c* l a , iff the source and destination 
service entities are instances of their respective classes of service entities, and the 
object associated with the link is an instance of the class associated with the class of 
links, i.e., 

/• c */ a e sr c^e^ rc a e dst ^e% st a o^c 

In the example presented in Figure [2] and [5] the link DeveloperBank is a full 
member of the class of links DeveloperBank a . First, DevHouse is an instance 
of the Experienced Developer" class. Second, MoniBank is an instance of 
Bank a class. Third, all the constraints — hasAccount and IcurrentLoans — 
defined in the class associated with the DeveloperBank" class of links are satis- 
fied by the object associated with the link DeveloperBank. 

Only class relational membership and link class full membership are defined in 
this paper, as the definition of other types of membership is out of the scope of this 
paper. 

5.3.3. Compliance with Service Network Schemata 

Based on the membership relations defined above, the concept of compliance 
with a service network schema may be defined. A service network is compliant with 
a service network schema if the constraints on the service entities and the social 
requirements among them, defined in a service network schema, are satisfied by a 
given service network. As presented formally below, various levels of compliance 
may be distinguished. 

Definition 1 1 (Compliance Relation) Consider a service network schema a a = ( E a , 
L a ) and a service network a = (E, L). A compliance relation =\ on a x o a is a relation 
such that 

\/(e,e a )eExE a , e=\e a ^ece a , (1) 
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V (' =< e src> e dst> C> ) eL > 

V ( e srC) e dst ) e E x E : e src =\ e% c) e dst =\ e a dsV 

3(l=<e src ,e dstf o>)eL: / # c # /", (2) 

Ve a eE a ,3eeE : eAe a . (3) 

First, the compliance of a service entity e with a class of service entities e a im- 
plies that that the service entity e is a relational member of the class of service en- 
tities e a (cf. Eq.[TJ. Second, for each class of links /" between two classes of service 
entities e" rc and e a dsV for each service entities e src and e dst being members of e" rc and 
e a dsV respectively, there exists a link between e src and e dst that is a full member of I (cf. 
Eq.[2). Third, for each class of service entities, at least one service entity is compliant 
with the class (cf. Eq.|3). 

Definition 12 (Compliance with a Service Network Schema) A service network a = 
(E,L) is compliant with a service network schema cr" = (E a ,L a ), denoted a =\ a a , iff 
there exists a compliance relation =i on o x o a . 

Definition 13 (Partial Compliance Relation) Consider a service network schema 
a a =< E a y L a > and a service network a =< E, L >. A partial compliance relation h on 
a x a a is a relation that satisfies only the conditions of equations [l] and [2] the third 
condition being relaxed. 

Definition 14 (Partial Compliance with a Service Network Schema) A service net- 
work a =< E y L > is partially compliant with a service network schema o a =< E a ,L a >, 
denoted a -\cr a , iff there exists a partial compliance relation h on a x cr a . 

Consider the service network schema presented in Figure[6]to illustrate the con- 
cepts of partial compliance. This service network schema is an extension of the ser- 
vice network schema formerly presented in Figure|i] with an additional class of ser- 
vice entities Site Preparation 6 * and an additional class of links Recommend". 

The compliance relation h applies to the following pairs of service entities and 
classes: 

• Archibald Tex — 1 Experienced Architect", 

• DevHouse — 1 Experienced Developer", and 

• MoniBank H Bank". 

Additionally, for each class of links between two classes of service entities among 
Experienced Architect", Experienced Developer", and Bank", there 
is a full member link between two service entities that are instances of the given 
classes. For example, the link Collaboration is a full member of the class of 
links Collaboration". As a consequence, both equations[l]and[2]are satisfied by 
the relation h. 
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Experienced Developer" 



#currentProjects: >2 



#pastProjects: >5 



a 



profession: D {Real-estate Developer} 



vestements: >1 



■currentLoans: =0 



Experienced Architect 01 

profession: D {Architect} 




Site Preparation 01 

employees: >2 



a Bank 01 

interestRate: > 5.5% 



Recommend a 



recommendedBy: = true 



Figure 6: A service network schema with which the service network defined in Figure[2]is partially com- 
pliant 



However, equation [5] is not satisfied, as no service entity of the service network 
presented in Figure|2]is an instance of the class of service entities Site Prepara- 
tion 61 . 

As a conclusion, the relation n formerly defined is a partial compliance relation, 
and therefore, the considered service network is partially compliant with the service 
network schema presented in Figure[6] 

5.4. Service Protocols 

The concept of service protocol may be defined at four levels: 

• at the abstract level, a service -oriented summary provides a service- oriented 
representation of a process model, a service network schema provides con- 
straints on service entities and social requirements, and additionally both the 
service- oriented summary and the service network schema are linked to asso- 
ciated service descriptions (from the service- oriented summary) with classes 
of service entities (from the service network schema); 

• at the prototype level, a service network is associated with both the service- 
oriented summary and the service network schema. At the prototype level, the 
service network provides only a partial implementation of an abstract service 
protocol, as some elements of the service- oriented summary and some classes 
of service entities of the schema may not be associated with any service entity 
of the service network; 
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• at the executable level the service network associated with both the service- 
oriented summary and the service network schema provides a complete im- 
plementation of an abstract service protocol: all the elements of the service- 
oriented summary and all the classes of service entities of the schema are as- 
sociated with service entities of the service network; 

• at the instance level, an executable service protocol is enacted. At the instance 
level, service entities defined at the executable level are consuming and pro- 
viding services modifying the state of the process model. 

This four-level approach to human interactions answers directly the two first re- 



quirements presented in Section 2.4 i.e., reusability and separation of activities im- 
plementation from service protocols. 

Definition 15 (Abstract Service Protocol) An abstract service protocol Y a is a triplet 

a 

Y a =< n® os ,o a , A >, where n® os is a service- oriented summary of a process model n a , 

a 

a a =< E a , L a > is a graph representing a service network schema, and A is a mapping 
relation between the service- oriented summary and the service network schema^] 

The mapping relation A : (S* a = SC a u SI a u SP a ) x E a associates elements of 
service descriptions — service consumer, service description and service provider 
classes — with classes of service entities of the service network schema. 

V(s* a ,e) e S* a xE a , s* a A e a means that the element of a service description 
s* a — sc a , si a , or sp a — is associated with the class of service entities e a of the service 
network schema. 

An example of an abstract service protocol is illustrated in Figure[7] The service- 
oriented summary of the abstract service protocol is represented at the top of the 
Figure. The service network schema is represented at the bottom of the Figure. 
The representation of the service network schema has been simplified to a graph 
representation for the sake of readability. A set of dashed arrows associates the 
elements of service descriptions of the service -oriented summary with the nodes 
of the service network schema represented by rounded rectangles labelled v { i } , 

a 

where i e [1,9]. This set of arrows represents the mapping relation A between the 
service- oriented summary and the service network schema. Therefore, the service 
consumer scl is associated with the class of service entities v6 of the service net- 
work schema. 

Additionally, the following relations among elements of service descriptions are 
defined: 

1. sc <consumes , = t rue > si, 

2. sp <provides , = t rue > si, 

3. si <isConsumedBy , = true> sc, 



5 The choice of the letter Y for service protocols may be explained by the Greek word "Ymripsaia" 
(Ypiresia) which means "service". 
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Figure 7: An abstract service protocol 
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4. si <isProvidedBy, 



= true> sp. 



Although implicit in service descriptions, these relations are not explicitly de- 
fined in the service network schema. However, the provides and isProvidedBy 
relations should be encompassed in service network schemata because these rela- 
tions define social constraints on service interfaces and their providers. The exten- 
sion of an existing service network schema to relations implicitly defined in service 
descriptions is an implicit service network schema. 

Definition 16 (Implicit Service Network Schema) The implicit service network sche- 
ma a a ' + =< E a ' + ,L a ' + > of an abstract service protocol is a supergraph of the ser- 
vice network schema o a =< E a ,L a ,>, i.e., a a ' + d cr a , such that E a,+ = E a and L a ' + = 
L a uL^, where is defined as follows: 

joe _ 

{<e£,ef,<provides, = true> >: (e^ef) e E a x E a f 

3sd=< sc,si,sp>e S^: sp Ae^ a siAe") 

u 

{<gf,^,<isProvidedBy f = t rue> >: (ef , e a p ) e E a x E a , 

a a ~ 

3sd=< sc,si,sp>e S^: sp Ae p a siAe") 



The implicit service network schema for the service network schema and the 
mapping function presented above is illustrated in Figure[8] On the top of the Figure, 
a simplified representation of a service -oriented summary is provided: only the ser- 
vice descriptions are represented. On the bottom of the figure, the service network 
schema already presented in Figure[7]is represented, together with the links related 
with relations between the elements of service descriptions. Solid arrows between 
nodes represent consumes links. Dot-dashed arrows between nodes represent 
isConsumedBy links. Dashed arrows between nodes represent isProvidedBy 
links. Dot arrows between nodes represent provides links. The implicit service 
network schema is the service network schema formerly presented in Figure [7] ex- 
tended by all the links presented in Figure[8] 

Definition 17 (Prototype Service Protocol) A prototype service protocol Y@ is a tu- 
ple Y@ =< Y a ,a,Q,0 >, where Y a is an abstract service protocol, a is a service net- 
work, and Q is a relation Q : Ex S* a associating service entities of the service network 
to elements of service descriptions, and <£> : E x E a associating nodes of the service 
network to classes of service entities of the service network schema of Y a . 
Let define the relation + : E x E a,+ as follows: 



V(e,e a > + )eExE a > + ,e® + e a 



e®e a > + 

v 

3s* a eS* a :(e Q s* a ) a (s* a A e a > + ) 
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3 Service-Oriented Summary; 

El Service description 1 : B Service description 2 EJ Service description 3 



iBJ iBJ Mj ; i s^J *g»J i^J : ! iBJ 




Figure 8: The implicit service network schema for the service network schema and the mapping func- 
tion A presented in Figure [7] Solid arrows between nodes represent consumes links. Dot-dashed 
arrows between nodes represent isConsumedBy links. Dashed arrows between nodes represent 
isProvidedBy links. Dot arrows between nodes represent provides links. 



In prototype service protocols, the relation + — referred further as the induced 
service relation — is a partial compliance relation on E x E a,+ (cf. Definition 14 . 

An example of a prototype service protocol is illustrated in Figure [9] At the top, 
the abstract service protocol of the prototype service protocol is represented. At the 
bottom, the service network of the prototype service protocol is represented in a 
simplified manner as a graph. Each service entity of the service network is repre- 
sented by a circle, some nodes being additionally labelled, e.g., the top-right service 
network node labelled ' 1 The links between service entities are represented by solid 
lines between the nodes. 

The relation Q mapping service entities of the service network to elements of 
service descriptions is represented on the left side of the Figure by dashed arrows. 
As an example, the top-right service network node labelled T is associated with the 
service interface s i 1 . 

Note that many service entities may be associated with a given service descrip- 
tion element. In Figure [9] both nodes labelled T and '2' are associated with the 
service interface s i 1 . 

Additionally, the relation O mapping nodes of the service network to classes of 
service entities of the service network schema is represented on the right side of the 
the Figure by dot- dashed arrows. As an example, the top -right service network node 
labelled T is associated with the class of service entities v7. 

Note that many service entities may be associated with a given class of service 
entities of the service network schema. In Figure [9] both nodes labelled '1' and '2' 
are associated with the class of service entities v7. 
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When a prototype service protocol is fully implemented, i.e., there is a service 
entity implementing each element of service description, then it may be executed. 
The service protocol is then an executable service protocol. 

Definition 18 (Executable Service Protocol) An executable service protocol Y € is a 
prototype service protocol such that V s* a e S* a ,3e € E such that e Q s* a , and the 



induced relation + :£x E a ' + is a compliance relation (cf. Definition 12 1 



Definition 19 (Service Protocol Instance) An instance of a service protocol Y is a 
pair Y = (Y e , s), where Y e is an executable service protocol, and s is the current state 
of the associated process model. 



6. Potential Applications 

In this section, potential applications of service networks are presented in three 
areas: in the construction sector, in public administration, and in healthcare. 

6.1. Potential Applications in the Construction Sector 

In the construction sector, many investment processes concern complex con- 
struction works, such as the building of a mall, a warehouse, a highway, or a resi- 
dential area. The realization of investment processes requires a multitude of varied 
competences usually provided by various organizations, such as architects, civil en- 
gineers, plumbing specialists, plant operatives, roofers, glaziers, and painters. 

The heterogeneity of the set of activities involved in the execution of investment 
processes is accompanied by potentially complex precedence rules concerning the 
execution of the activities within a given investment process. As consequence, the 
execution of investment processes may be supported by appropriate process mod- 
els specifying the precedence rules concerning the execution of activities. 

Additionally, social aspects are playing an important role in the human interac- 
tions in the construction sector. Among various important social aspects, one may 
distinguish the history of former collaboration among organizations as a social as- 
pect that usually influences the choice of collaboration partners. Similarly, the rec- 
ommendation of an organization by another organization is a frequent situation in 
the construction sector, influencing here again the choice of collaboration partners. 
Trust is another social aspect having an important influence on the collaboration in 
the construction sector. As a consequence, the execution of investment processes, 
including the choice of collaboration partners, may be supported by encompassing 
the social network of the organizations in the construction sector in a given geo- 
graphical area. 

The encompassing of both process models and social networks leads to service 
protocols. Therefore, the execution of investment processes may be supported by 
service protocols, encompassing both process models and the social network of the 
organizations in the construction sector. 

The four levels of abstraction of service protocols may be applied in the con- 
struction sector as follows: 



26 



• An abstract service protocol represents a given type of building investment 
projects and the rules associated with this type or, at least, part of such projects. 
To some extent, an abstract service protocol may document best practices that 
may potentially be reused by various organizations. As an example, an ab- 
stract service protocol may define the activities needed to lay down concrete 
foundations of a supermarket as a process model, e.g., concrete stab pouring 
is followed by concrete levelling and drying. Next, the abstract service proto- 
col defines the types of organization needed to perform these activities and 
the mandatory relationships between these types of organizations as a service 
network schema, e.g., the architect should trust the concrete contractors; 

• A prototype service protocol represents the implementation of a given type of 
building investment projects by a given organization. As an example, a real- 
estate developer may already have some preferences concerning the concrete 
contractors they are collaborating with, even if the choice of the architect is 
not fixed. Another real- estate developer may use a different prototype service 
protocol based on the same abstract service protocol concerning foundations 
laying: he/she may have a partnering architect but no partnering concrete 
contractors; 

• An executable service protocol represents a complete implementation of a given 
type of building investment projects by a given organization. In an executable 
service protocol, all the organizations and services needed to implement the 
associated prototype service protocol are identified. As an example, consider 
an executable service protocol based on the prototype service protocol con- 
cerning the laying of foundations by the real- estate developer having a part- 
nering architect. At the executable level, the concrete contractors are iden- 
tified, as well as the services that they may provide or consume during the 
execution of the associated abstract service protocol; 

• A service protocol instance supports the execution of a given building invest- 
ment project or at least a part of it. As an example, the execution of the for- 
merly presented executable service protocol leads to a service protocol in- 
stance executed by the partnering architect and the chosen concrete contrac- 
tors. Besides the set of organizations and services, a service protocol instance 
has a state associated with the process model of the related abstract service 
protocol. As an example, a service protocol instance concerning foundations 
laying may be in the state "concrete leveling". 

6.2. Potential Applications in Public Administration 

In public administration, many administrative procedures concern complex ad- 
ministrative cases, such as the delivery of a construction permit, the processing of 
income taxes, the renewal of a passport. Similarly to the construction sector, the 
execution of administrative procedures requires various competences usually pro- 
vided by various agencies, such as Internal Revenue Service (IRS), city's Department 
of Buildings, Passport Agencies. 
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Regulations constrain the competences of both clerks and agencies in adminis- 
trative procedures. Regulations also often define precedence rules concerning the 
execution of the activities. As a consequence, the execution of administrative proce- 
dures may be supported by appropriate process models. In many public agencies, 
administrative procedures are already supported by IT systems. 

Additionally, some administrative procedures define constraints concerning so- 
cial aspects. A common type of social requirements found in administrative proce- 
dure concerns sibling relations. As an example, passport delivery for a child usually 
requires the presence of the child's parents or guardians at the agency at submis- 
sion time. Many administrative procedures also require that the applicant lives in 
a particular geographical area related with the appropriate agency. As an example, 
the delivery of a construction permit is usually performed by a local agency whose 
jurisdiction with regard to construction permit delivery is geographically limited. 
As a consequence, the execution of administrative procedures may be supported by 
encompassing the social network of agencies and applicants, either natural or legal 
persons. 

The encompassing of both process models and social networks in public admin- 
istration leads to service protocols, in a similar manner as in the construction sector. 
Therefore, the execution of administrative procedure may be supported by service 
protocols, encompassing both process models and the social network of agencies 
and applicants. 

The four levels of abstraction of service protocols in public administration may 
be applied as follows: 

• An abstract service protocol represents a given administrative procedure or, 
at least, part of such a procedure. To some extent, abstract service protocol 
may serve as models of regulation concerning a given procedure. As an ex- 
ample, an abstract service protocol may define the activities needed to de- 
liver a United States of America passport to a child as a process model, e.g., 
the data — fulfilled forms, pictures, fingerprints — are gathered at a passport 
agency, next the data are checked, and then the passport is printed by the 
United States Government Printing Office. Next, the abstract service protocol 
defines the types of agencies and applicants needed to perform these activities 
and the mandatory relationships between them as a service network schema, 
e.g., the child's parents or guardians have to fulfil and submit the forms; 

• A prototype service protocol represents an implementation of an administra- 
tive procedure by a given agency. As an example, a given passport agency may 
have already some preferences concerning chosen aspects of the procedure, 
e.g., the Buffalo Passport Agency does not require travel plans to be presented 
to apply for a passport. Another Passport Agency, such as the Western Passport 
Center, requires a proof of international travel within 2 weeks of the appoint- 
ment or a proof of emergency abroad; 

• An executable service protocol represents a complete implementation of a given 
administrative procedure. Therefore, in an executable service protocol, all the 
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agencies, applicants, and services needed to implement the associated pro- 
totype service protocol are identified. As an example, consider an executable 
service protocol based on the prototype service protocol concerning the de- 
livery of a passport at the Buffalo Passport Agency At the executable level, 
the clerk, the child, the parents or guardians are identified, as well as the ser- 
vices that they may provide or consume during the execution of the associ- 
ated abstract service protocol, such as providing the photography of the child 
or checking that the forms have been correctly fulfilled; 

• A service protocol instance supports the execution of an administrative pro- 
cedure or, at least, a part of it. As an example, the execution of the formerly 
presented executable service protocol leads to a service protocol instance ex- 
ecuted by the Buffalo Passport Agency. Besides the clerk, the child, the parents 
or guardians, and services, a service protocol instance has a state associated 
with the process model of the related abstract service protocol. As an exam- 
ple, a service protocol instance concerning passport delivery may be in the 
state "passport waiting for printing by the United States Government Printing 
Office". 

6.3. Potential Applications in Healthcare 

In healthcare, two types of processes may be distinguished. First, many pro- 
cedures in healthcare are administrative procedures, e.g., patient registration and 
scheduling, drugs management, medical record management. Second, key proce- 
dures in healthcare are medical procedures related with patient healing, e.g., surgery 
operation, vaccination, broken bone immobilization. 

These two types of processes share a set of common characteristics. First, the 
execution of activities of these processes often requires certified competences: only 
a pharmacist is allowed to manage drugs at a hospital, only anaesthesiologists — 
eventually nurse anaesthetists in some countries — are allowed to perform anaes- 
thesia. Second, precedence rules are important for both administrative and medical 
procedure: a patient has to be registered before she/he may be examined by a physi- 
cian, an X-ray radiography precedes the immobilization with a plaster or fibreglass 
cast. Third, the number of competences involved in the administrative and medical 
procedures is usually high. 

Similarly to the processes in the construction sector and public administration, 
the execution of both administrative and medical procedures may be supported by 
appropriate process models. Support for administrative procedure by IT systems 
is already implemented in many healthcare facilities. Computer support for medi- 
cal procedures is rapidly becoming popular with advanced imaging techniques and 
robotics. However, support for the process facet of medical procedures is still to be 
widely implemented and accepted. 

Additionally, social aspects are playing an important role in some healthcare 
procedures. First, administrative procedures may restrict relations between the pa- 
tients and the healthcare facilities. As an example, in the Polish healthcare system, a 
patient has to consult a primary care physician, also known as family physician, that 
may further redirect the patient to a medical specialist. The primary care physician 
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and the patient have to be located in the same geographical area. Second, a medical 
procedure may also constrain relations between persons involved in the procedure. 
As an example, consider a live donor transplantation. In this transplantation oper- 
ation, part of the liver of an parent, sometimes a sibling, is transplanted to another 
person, usually a child. The parent and the child have to share the same blood type, 
the donor should be have a similar or bigger size than the recipient. As a conse- 
quence, the execution of healthcare procedures maybe supported by encompassing 
the social network of patients and healthcare personnel. 

The encompassing of both process models and social networks leads to service 
protocols. Therefore, the execution of healthcare procedures may be supported by 
service protocols, encompassing both process models and the social network of pa- 
tients and the healthcare personnel. 

The four levels of abstraction of service protocols may be applied as follows in 
healthcare: 

• An abstract service protocol represents a given administrative or medical pro- 
cedure. To some extent, abstract service protocol may serve to document best 
practices that may potentially be reuse by various healthcare facilities. As an 
example, an abstract service protocol may define the activities needed to per- 
form a live donor liver transplantation, as well as the relations between the 
donor and the recipient; 

• A prototype service protocol represents the implementation of a healthcare 
procedure at a given healthcare facility. As an example, a hospital may already 
have some preferences concerning the accommodations of the donor and the 
recipient in adjacent rooms. Another hospital may have a different approach, 
separating donors from recipients; 

• An executable service protocol represents a comprehensive implementation of 
a healthcare procedure by a given facility. In an executable service protocol, 
all the patients, the medical personnel, and services needed to implement the 
associated prototype service protocol are identified. As an example, consider 
an executable service protocol based on the prototype service protocol con- 
cerning the live donor liver transplantation at the healthcare facility accom- 
modating the donors and patients in adjacent rooms. At the executable level, 
the patients, the surgeon, the anaesthesiologist, and the nurses are identified, 
as well as the services that they may provide or consume during the execution 
of the associated abstract service protocol; 

• A service protocol instance represents the execution of a given healthcare pro- 
cedure. As an example, the execution of the formerly presented executable 
service protocol leads to a service protocol instance executed by the patients 
and the healthcare personnel. A service protocol instance has a state asso- 
ciated with the process model of the related abstract service protocol. As an 
example, a service protocol instance concerning live donor liver transplanta- 
tion may be in the state "donor and recipient in post anaesthesia care unit". 
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7. Discussion 

In this section, first, positive aspects of service protocols are presented. In a sec- 
ond part, limitations of service protocols are detailed. 

Among positive aspects of service protocols, the support for social requirements 
has to be highlighted. First, the concept of social requirement is clearly defined in 
this paper as class of links between service entities. To our best knowledge, this is 
the first definition of social requirement in the SOA context. Second, service net- 
work schemata, in which social requirements and requirements concerning service 
entities themselves, are formally defined, based on graphs. The formalized model of 
service protocols is therefore based on fully formalized concepts relying on sound 
foundations (object orientation, graph theory, BPM, SOA). Additionally, sound foun- 
dations for service protocols would ease the development of tools to design, man- 
age, and validate service protocols. 

Another interesting characteristic of service protocols is their service orienta- 
tion. With the wide adaptation of SOA, even if in many cases just at the Web service 
level, the underlying concepts of service protocols, i.e., service consumer, service 
interface, service provider, are broadly accepted and understood. Therefore, the 
learning curve for service protocols should be smooth and not steep. 

In the presented approach, the instantiation of service protocols assumes the ex- 
istence of a service network in which a set of available service entities and their rela- 
tions is represented. Many social websites are currently publishing personal data of 
private users and their relations. Social networks has came to the public awareness 
with the recent success of social websites, such as Facebook |9 |, Qzone |25|, Twit- 
ter (30), MySpace [19), Linkedln 1 16], or Orkut ED, just to name a few. With more 
than 800 million active users announced by Mark Zuckerberg during the F8 confer- 
ence [10) on September 22, 2011, the possibility to build large networks is demon- 
strated, and it is probably correct to assess that social or service networks will be a 
stable element of the future IT landscape. 

In the context of service networks, choosing service entities in a large service net- 
work is an interesting characteristic from the perspective of the adaptation of service 
protocols. As in (24), the adaptation of service protocols refers in this paper to the 
capability of a group of human interacting according to a given service protocol to 
modify the service protocol at run-time to react to changing conditions, external or 
internal to the group of interacting humans. When a group has to adapt the service 
protocol ruling its interactions, a frequent task is the deletion/ replacement/ addition 
of new collaborators /tools. Having in mind that more than half of all the employers 
(53% according Holzer [15), 60% according to Bewley |5 |) are seaking future employ- 
ees on the social networks of their employees, adaptation of service protocols may 
take a serious advantage of the service network underlying service protocols. 

Finally, a solution to the problem of the instantiation process for service proto- 
cols have already been proposed: a method for partner and service selection based 
on social protocols (which are a particular type of service protocols) is presented 
in |22|. In this method, first, a set of service entities covering the functionalities 
required for the process to run is selected by selecting members of classes of ser- 
vice entities from a service network. Second, a set of potential groups of partners 
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are created using a generic algorithm within with social requirements, expressed as 
classes of links among service entities, are used to evaluate and filter out inappro- 
priate groups. The method presented in |22) is fully implemented. 

Among drawbacks, the lack of semantics associated with property names and 
property constraint names may be distinguished. It is highly probable that various 
service protocol designers are using different words to refer to the same property. 
As an example, a property name my Languages may have some semantic relation, 
e.g., be a synonym, with a property name support edLanguages. A more com- 
plex case may be the semantic relation between geographicalLocation and 
count ry. Semantic relations may exist not only among property names, or among 
property constraint names, but among exist between a property name and a prop- 
erty constraint. Consider a property constraint p a named geographicalLoca- 
tion with the value = Indonesia and a property p named country with the 
value Indonesia. Without the semantic relation between geographicalLoca- 
tion and country, p does not satisfy p a . A support for semantics could improve 
the representation of classes of service entities, class of links between service enti- 
ties, service entities, and links between service entities. 

Another limitation of service protocols is its limited expressive power. In its cur- 
rent form, the expressivity of service protocols does not encompass constraints con- 
cerning neither the cardinality of class members, nor alternatives. Constraints con- 
cerning the cardinality would capture for example that in a given process more than 
2, but less than 20, programmers are required, or that exactly 3 architects are re- 
quired. Alternatives on classes may for example capture the fact that either a certi- 
fied architect or a senior developer are needed in a given social protocol. Currently, 
service protocols do not support the specification of such requirements. 

Finally, an important limitation concerning service protocols is the lack of vali- 
dated methodology concerning the design of service protocols. Various approaches 
to service protocol design may be considered: one may start by designing a process 
model, then a service -oriented summary may be built for the process model, next a 
service network schema may be designed, and finally, the service network schema 
may be linked with the service- oriented summary. The second approach may start 
with the specification of a service network schema, next service descriptions may be 
defined and associated with classes of service entities, and finally service descrip- 
tions may be associated with activities structured by a process model. To our best 
knowledge, methodologies for the design of service protocols are still to be devel- 
oped. 

8. Conclusions 

In this paper, the concept of service protocol has been presented and fully for- 
malized. Service protocols are based on sound foundations in the areas of graph 
theory, SOA, and BPM. However, the combination of concepts from these areas is 
innovative as the proposed model goes far beyond recently proposed ideas such as 
Social BPM or ACM. 
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A major contribution to the modelling of human interactions is the introduc- 
tion of service network schemata. The integration of service network schemata with 
process models leads to a model of human interactions supporting not only the def- 
inition of the potential sequences of interactions, but also the definition of the ex- 
pected properties of actors and their relations required for the process to be exe- 
cuted. As a consequence, a service protocol may be considered as a model defining 
the "composition" of a group within which interactions are structured by a given 
process model. Service protocols capture social requirements for process models 
in service network schemata and the link between schemata and service- oriented 
summaries. 

Another major contribution to the modelling of human interactions is a unified 
approach organized around the concept of service. It should be clearly stated that, 
in this paper, the word service has a broader meaning than just Web service, encom- 
passing not only service provided by software entities, but also services provided by 
humans and organizations. As a consequence, in the proposed model, process mod- 
els are summarized with service descriptions, social requirements are modelled as 
classes of service entities and classes of links among service entities. Note that the 
concept of service description which is directly associated with process activities is 
a triplet consisting of service consumers, service interfaces, and service providers. 
Such a representation of process activities is more general than representation of 
process activities in BPEL: in BPEL, a service may be reduced to its interface and 
its service provider, the service consumer being the BPEL engine. Process models 
in which the service consumer is actually consuming services may be supported by 
the proposed model. 

Among future works, performance and scalability of the proposed model is an 
issue that requires more efforts. Although checking if a service network is compliant 
with a service network schema is a relatively easy task, identifying within a large ser- 
vice network a service sub -network that is compliant with a service network schema 
is a complex task. To our best knowledge, algorithms to perform this search task ef- 
ficiently are still to be developed. Another topic in which further work is needed are 
semantic issues related to property names and property constraint names. In its cur- 
rent version, the potential semantic relations among property names, among prop- 
erty constraint names, and among property names and property constraint names 
are not taken into account. Finally, although a pilot application has been developed, 
validating the feasibility of a prototype supporting the presented model, validation 
of the pertinence of this model requires an application in real-world cases. The pi- 
lot application is currently tailored to the needs of the construction sector with a 
scenario involving a real-estate developer enterprise and its subcontractors. In this 
business environment, social requirements play an important role: examples of re- 
current social elements are frequent recommendation of one SME by another or 
cooperation history on past construction places. 
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